Introduction

This notebook gives an introduction and overview of the codebase/API involved in the thesis project titled: "High Performance Computing for Evaluating Volume Massing Designs". The codebase is intended to work as a standalone API executable so the reasoning behind this jupyter notebook is to provide a transparent overview of the APIs capabilities. The codebase is supplemented by a thesis report with litterature study and a walkthrough of the engines used in the codebase. Examples of thesis report ready text can be found here:

Week 4 report ready text: https://1drv.ms/b/s!ArT2Rk1rI-5viIZ8DYLSjZLuU3-yng?e=SwQXpJ

Week 5 report ready text: https://1drv.ms/b/s!ArT2Rk1rI-5viIkdBSnb9n6r9rLXmg?e=ZmfKBs

API structure overview

The main goal of the API is to serve as a tool for conducting volume massing design studies. A volume massing design study is an architectural process of defining the polygon boundaries of a new building within an existing building context, based on building performance simulations. The structure of the API is originally inspired by: https://pure.au.dk/portal/da/publications/building-performance-simulation-supporting-typical-design-activities-the-case-of-volume-massing(1b3a413f-bf5d-4b28-94ab-6e287939f4d9).html

The general structure of the API is as follows:

image-4.png

Innovations

One of the main innovations from this API compared to previous work and other related software packages is the use of GPU based raytracing. Furthermore the API will work out of the box and not require any detailed knowledge about the underlying engines (the API makes justifiable assumptions for you). The API will be CAD agnostic working as an independant executable. Lastly several "experimental" approaches for speeding up computation time is implemented as laid out by the version overview/roadmap below.

Engines

Several building performance simulation engines are called by the API. They have been selected as industry standard and have all been validated against physical real world measurements and/or are based on relevant industry standards.

Radiance: CPU based raytracing engine

https://www.radiance-online.org/

Accelerad: GPU based raytracing engine

https://nljones.github.io/Accelerad/

Modelled after Radiance

ICEbear: Whole building energy simulation

http://www.idbuild.dk/icebear

Very fast simulation engine for early stage design energy simulation. Based on ISO 13790.

EnergyPlus: Whole building energy simulation

https://energyplus.net/

Extensive simulation engine, with possibilities for modelling with a high level of detail.

Versions overview (roadmap)

This is a development roadmap of the API versions. The reasoning behind developing the API with multiple versions is to be able to narrate the changes in implementation and their effect on speed and accuracy.

Baseline implementation (currently under development):

Implementation of the conventional approach to volume massing design. The daylight analysis and radiation analysis is based on Radiance. The energy analysis is based on EnergyPlus. That is - all computations are CPU based.

This implementation will serve as a benchmarking baseline in terms of speed for the other versions. Also this implementation will serve a as basis for comparing results.

Version 0.0.1:

Same as baseline implementation except changing Radiance function calls (CPU based raytracing) to Accelerad function calls (GPU based raytracing).

Version 0.0.2:

Same as version 0.0.1 except: Relying on database of .smx. Reusing ambient calcuation between radiation and daylight simulation. Computing in one channel, instaed of 3 color channels.

Version 0.0.3:

Same as version 0.0.2 except: Implementing ICEbear instead of EnergyPlus.

Version 0.0.4:

Same as version 0.0.3 except: Keeping output from Accelerad rfluxmtx in GPU memory instead of writing it to stdout (as is the way rfluxmtx is implemented). Performing GPU based matrix multiplikation.

Baseline implementation - Radation analysis

This is a walkthrough of the steps involved for conducting a radiation analysis using the baseline version (all of the below functions calls can be run by simply calling recipes.radiationanalysis as well).

Step 1: Recieve input geometry from independant CAD/front-end in .rad (radiance) format:

First step is to recieve a geometry input in .rad (radiance) format from a frontend. Alternatively the input geometry can be defined in a text editor. The input geometry is subdived into: volume massing facades (the vertical surfaces of the design), the rest of the volume massing and the context (surrounding buildings). There is also an example folder included in the API with examples.

Step 2: Get additional user input from front-end

Some additional input i required from the user/front end as follows:

Based on these inputs a object containing all relevant path definitions is createad:

Step 3: .epw file to .smx matrix

Next step in the radiation analysis is to convert the epw file data (direct normal radiation and diffuse horizontal radiation) to a Tregenza discretized Perez all-weather sky model for all 8760 hours in the year:

Step 4: Create radiation measurement point and mesh corresponding to each point

Then it is needed to create virtual sensorpoints and corresponding meshes to color based on the result on the facades of the volume massing:

Step 5: Creating daylight coefficient matrix for radiation analysis

Next from each sensor-point, the daylight coefficients to the sky can be calculated:

Step 6: Matrix multiplikation and rgb conversion

And Lastly dctimestep is used to perform the Matrix multiplication E = DC x S. And since Radiance computes in three channels rmtxop is used to compute the final result - radiation on the facades